اشتراک‌ها
Microsoft و ارائه زبان P

Microsoft has made P, its event-driven programming language, open source. P is designed to give developers a way to write safe asynchronous event-driven programs.

Microsoft و ارائه زبان P
اشتراک‌ها
زبان برنامه‌نویسی J یک زبان سطح بالا و پرتابل و دارای قابلیت Memory Map File

J (J language) is a high-level, general-purpose, high-performance programming language. J is portable and runs on 32/64-bit Windows/Linux/Mac as well as iOS, Android, and other platforms. J source (required only if Jsoftware binaries don't meet your requirements) is available under both commercial and GPL 3 license. J systems can be installed and distributed for free.

J systems have:

  • an integrated development environment
  • standard libraries, utilities, and packages
  • console, browser, and Qt front ends
  • interfaces with other programming languages and applications
  • integrated graphics
  • memory mapped files for high performance data applications
  • Jd 
زبان برنامه‌نویسی J  یک زبان سطح بالا و پرتابل و دارای قابلیت Memory Map File
نظرات مطالب
C# 7 - Tuple return types and deconstruction
بهبود نحوه‌ی انتساب Tuples در حین deconstruction در C# 10.0
پیشتر از یکی از دو روش زیر برای تعریف و مقدار دهی متغیرهای حاصل از deconstruction می‌شد استفاده کرد؛ یا استفاده از var برای هر دو و یا تعریف و مقدار دهی هر دو خارج از deconstruction:
Car car = new("Test", "Blue");

var (model, color) = car;
// Initialization

string model = string.Empty;
string color = string.Empty;
(model, color) = car;
// Assignment
در C# 10.0 این محدودیت برطرف شده‌است و هر دو حالت را می‌توان با هم داشت:
string model = string.Empty;
(model, var color) = car;
// Initialization and assignment
مطالب
نکات ویژه کار با عملیات نامتقارن در Blazor Server
 در برنامه‌های Blazor Server، تنها از یک نخ رابط کاربری واحد ( single UI thread ) استفاده نمی‌شود؛ بلکه هر نخی که در دسترس باشد، می‌تواند در موقع رندر، استفاده شود. علاوه بر این اگر از عملیات نامتقارن استفاده شود، زمانیکه به کلمه‌ی کلیدی await می‌رسیم، آنگاه نخ اختصاص داده شده‌ی برای ادامه پردازش متد، ممکن است لزوما همان چیزی نباشد که آن را شروع کرده است. برای نشان دادن این موضوع مثالی را در پیش می‌گیریم.
کامپوننتی را با نام  SynchronousInitComponent با کد زیر درنظر می‌گیریم. همانطور که از اسم آن مشخص است این کامپوننت به صورت متقارن یا همزمان پیاده‌سازی شده است:
<p>Sync rendered by thread @IdOfRenderingThread</p>

@code
{
  int IdOfRenderingThread;

  protected override void OnInitialized()
  {
    base.OnInitialized();
    IdOfRenderingThread =
      System.Threading.Thread.CurrentThread.ManagedThreadId;
  }
}
در حقیقت در متد OnInitialized آن، مقدار نخ جاری را توسط Thread.ManagedThreadId به دست می‌آوریم. بنابراین شماره نخ جاری پس از رندر شدن کامپوننت، در صفحه نمایش داده می‌شود.
حال در کامپوننت دیگری برای مثال کامپوننت index، کامپوننت همزمان فوق را به شکل زیر فراخوانی می‌کنیم:
@page "/"

<h1>Components with synchronous OnInitialized()</h1>
@for (int i = 0; i < 5; i++)
{
  <SynchronousInitComponent />
}
با این نتیجه:
Components with synchronous OnInitialized()
Sync rendered by thread 4
Sync rendered by thread 4
Sync rendered by thread 4
Sync rendered by thread 4
Sync rendered by thread 4
همانطور که ملاحظه می‌نمایید شناسه نخ یکسانی برای هر فراخوانی کامپوننت نشان داده می‌شود. بدیهی است در صورتیکه شما همین کد را اجرا کنید، ممکن است شماره نخ برنامه شما با کد من یکی نباشد؛ اما نتیجه یکی است. یعنی در تمامی موارد، یک عدد مشاهده می‌شود.
حال همین آزمایش را با متدهای نامتقارن یا ناهمزمان انجام می‌دهیم. کامپوننت AsynchronousInitComponent را با کد زیر درنظر بگیرید:
<p>Async rendered by thread @IdOfRenderingThread</p>

@code
{
  int IdOfRenderingThread;

  protected override async Task OnInitializedAsync()
  {
    // Runs synchronously as there is no code in base.OnInitialized(),
    // so the same thread is used
    await base.OnInitializedAsync().ConfigureAwait(false);
    IdOfRenderingThread =
      System.Threading.Thread.CurrentThread.ManagedThreadId;

    // Awaiting will schedule a job for later, and we will be assigned
    // whichever worker thread is next available
    await Task.Delay(1000).ConfigureAwait(false);
    IdOfRenderingThread =
      System.Threading.Thread.CurrentThread.ManagedThreadId;
  }
}
این کامپوننت هم دقیقا شبیه کامپوننت قبلی است؛ با این تفاوت که IdOfRenderingThread، مجددا بعد از یک تاخیر یک ثانیه‌ای مقداردهی شده‌است. این مقداردهی سبب رندر مجدد کامپوننت با تاخیر یک ثانیه می‌شود. حال در کامپوننت دیگری، کامپوننت غیرمتقارن فوق را به شکل زیر فراخوانی می‌کنیم:
@page "/async-init"

<h1>Components with asynchronous OnInitializedAsync()</h1>
@for (int i = 0; i < 5; i++)
{
  <AsynchronousInitComponent/>
}
با اجرا کردن برنامه، دقیقا نتایج، شبیه نتایج نتایج کامپوننت متقارن می‌باشد:
Components with asynchronous OnInitializedAsync()
Async rendered by thread 4
Async rendered by thread 4
Async rendered by thread 4
Async rendered by thread 4
Async rendered by thread 4
اما تنها بعد از یک ثانیه (await Task.Delay(1000)) ، متدهای OnInitializedAsync کامپوننت‌ها، به پایان می‌رسند و مقدار IdOfRenderingThread را پیش از به پایان رسیدن رندر صفحه، به روز رسانی می‌نمایند. اینبار، دیگر مقادیر نخ‌ها متفاوت خواهند بود:
Components with asynchronous OnInitializedAsync()
Async rendered by thread 7
Async rendered by thread 18
Async rendered by thread 10
Async rendered by thread 13
Async rendered by thread 11
با توجه به مطالب مطرح شده به این نتیجه می‌رسیم که این موضوع می‌تواند هنگام استفاده از یک وابستگی غیر ایمن ( non-thread-safe dependency ) مانند DBContext در چندین کامپوننت باعث بروز مشکل شود. نمونه‌ای از نحوه‌ی رویارویی با مشکلات احتمالی آن، در اینجا و اینجا بررسی شده‌است.  
نظرات مطالب
پردازش‌های Async در Entity framework 6
با سلام؛ من از کد زیر استفاده کردم اما همواره خطا میده.
توی serviceLayer :
        public async Task<IList<NewsSliderModel>> GetNewsSliderTable(CancellationToken cancellationToken = default(CancellationToken))
        {
            IQueryable<News> selectednews = _news.Take(_sliderTakeCount).AsQueryable();
             ...
             ...
            return await selectednews.Select(x => new NewsSliderModel
            {
                NewsId = x.Id,
                Title = x.Title,
                ImagePath = x.ImagePath,
                ImageTitle = x.ImageTitle,
                ImageDescription = x.ImageDescription,
            }).ToListAsync();

        }
و توی کنترلر Home برنامه
        public virtual async Task<ActionResult> MainSlider()
        {
            IList<NewsSliderModel> SliderList = await _newsService.GetNewsSliderTable(Order.Descending, NewsOrderBy.Id);
            return PartialView(MVC.Home.Views._MainSlider, SliderList.ToList());
        }
اما همواره خطای زیر رو میده
HttpServerUtility.Execute blocked while waiting for an asynchronous operation to complete.
ممنون میشم راهنمایی فرمایید
مطالب
روش ترجیح داده شده‌ی مقایسه مقادیر اشیاء با null از زمان C# 7.0 به بعد
روش سنتی بررسی نال بودن اشیاء و متغیرها در زبان #C، استفاده از اپراتور == است:
if(person == null) { }
اما از زمان C# 7.0 و معرفی pattern matching، از واژه‌ی کلیدی is نیز می‌توان برای اینکار استفاده کرد (که به آن constant pattern هم می‌گویند):
if(person is null) { }
اکنون سؤال اینجا است که امروز بهتر است از کدامیک استفاده کنیم؟


سربارگذاری عملگرها و مقایسه‌ی وهله‌های اشیاء با null

در عمل، تفاوتی بین استفاده‌ی از عملگر == و واژه‌ی کلیدی is برای بررسی نال بودن وهله‌ای از یک شیء وجود ندارد؛ اما ... با یک شرط! فقط در حالتیکه عملگر == سربارگذاری نشده باشد.
برای نمونه کلاس Person زیر را در نظر بگیرید که عملگرهای == و =! آن بازنویسی شده‌اند:
public class Person
{
  public static bool operator ==(Person x, Person y)
  {
    return false;
  }
  public static bool operator !=(Person x, Person y)
  {
    return !(x == y);
  }
  public override bool Equals(object obj)
  {
    return base.Equals(obj);
  }
}
در این حالت اگر قطعه کد زیر را اجرا کنیم که در یک سطر آن، وهله‌ی person که مقدار نال را دارد، توسط عملگر == با null مقایسه شده‌است و در سطر بعدی با کمک واژه‌ی کلیدی is با نال مقایسه شده‌است:
Person person = null;
Console.WriteLine("Is Person null?");
Console.WriteLine($"== says: {person == null}");
Console.WriteLine($"is says: {person is null}");
به نظر شما خروجی این قطعه کد چیست؟
اگر در کلاس Person سربارگذاری عملگر == صورت نمی‌گرفت، خروجی زیر را مشاهده می‌کردیم:
Is Person null?
== says: True
is says: True
اما اینبار خروجی واقعی قطعه کد فوق، با چیزی که انتظار داریم متفاوت است:
Is Person null?
== says: False
is says: True
مزیت کار با واژه‌ی کلیدی is، صرفنظر کردن از operator overloads یا همان سربارگذاری عملگرها است. در حین حالت فقط مقدار person، با null مقایسه می‌شود و دیگر، کار به بررسی خروجی false زیر نمی‌رسد (کاری که با استفاده از عملگر == حتما انجام خواهد شد):
public static bool operator ==(Person x, Person y)
{
   return false;
}
به عبارتی استفاده‌ی از عملگر == جهت مقایسه‌ی با null، حتما نیاز به بررسی کدهای کلاس Person را جهت مشاهده‌ی کدهای تغییر یافته‌ی عملگر == را نیز دارد؛ اما زمانیکه از وژه‌ی کلیدی is استفاده می‌کنیم، مقصود اصلی ما را که بررسی مقدار جاری با null است، برآورده می‌کند (و در 99 درصد موارد، ما هدف دیگری را دنبال نمی‌کنیم و برای ما مهم نیست که عملگر == سربارگذاری شده‌است یا خیر). همچنین سرعت مقایسه در حالت استفاده از واژه‌ی کلیدی is نیز بیشتر است؛ چون دیگر فراخوانی کدی که عملگر == را سربارگذاری می‌کند، صورت نخواهد گرفت و از زمان C# 9.0، برای حالت بررسی حالت عکس آن می‌توان از  if (obj is not null) نیز استفاده کرد (بجای if (!(obj is null))) که از حالت سربارگذاری عملگر =! صرفنظر می‌کند.


یک نکته: null coalescing operator یعنی ?? و null coalescing assignment operator یعنی =?? نیز همانند واژه‌ی کلیدی is عمل می‌کنند. یعنی از == سربارگذاری شده صرفنظر خواهند کرد.